Add bindings for pg_query_deparse_protobuf - #32

libpg-query exposed only the parse half of libpg_query. Getting SQL back out
of an AST meant reaching for pgsql-deparser, a hand-written TypeScript
reimplementation of Postgres' deparseRawStmt that has to track a C file
changing every major release.

libpg_query has shipped pg_query_deparse_protobuf() since 2.x — it's present
at every tag this repo builds. The blocker was the one PR constructive-io#32 hit in 2023: it
takes a protobuf-encoded parse tree, and protobufjs ignores the json_name
option. pg_query.proto leans on 1,683 of those annotations to map JSON keys
like SelectStmt and targetList onto snake_case proto fields, so the tree
parse() returns can't be re-encoded. PR constructive-io#32 worked around it by vendoring a
96k-line static model generated from a protobufjs fork.

@bufbuild/protobuf honours json_name, so the fix is now just: generate
schemas, fromJson -> toBinary, hand the bytes to a new WASM entrypoint.

  import { parse, deparse } from 'libpg-query';
  await deparse(await parse('select a,b   from   t'));  // SELECT a, b FROM t

New @ashbyhq/pgsql-proto package (proto/) holds the generated codecs, one per
major version behind ./v13../v18 subpaths. All protobuf-es usage stays behind
an encodeParseTree(tree) -> Uint8Array facade so consumers don't inherit its
moduleResolution: node16 requirement. Generated schemas are committed, so
neither CI nor consumers need a protobuf toolchain.

The C wrapper returns the PgQueryDeparseResult struct rather than a bare
string, so a deparse failure is distinguishable from a query starting with the
word "error" and surfaces real PgQueryError details. Encoding is strict: a
misspelled field or bogus enum value throws instead of being dropped and
deparsed into quietly wrong SQL.

libpg_query grew pg_query_deparse_protobuf_opts and
pg_query_deparse_comments_for_query in its 18 line — present in both pganalyze
18.0.0 and the constructive fork we build v18 from, absent from every 13-17
tag. So v18 additionally gets pretty-printing and comment preservation via
extractComments(); on 13-17 those options are accepted and ignored, keeping
one call signature across versions.

Three pre-existing problems had to be fixed to land this:

- copy:templates was silently reverting v15/v17/v18 to upstream libpg_query.
  Their Makefiles carried hand-edited fork overrides the template didn't
  model, so regenerating pointed v18 at a branch that doesn't exist upstream.
  Repo and ref now live in x-publish.

- v13's WASM build was broken; CI worked around it by downloading a prebuilt
  tarball, which would have shipped a v13 without the new exports. The
  spinlock patch adds a configure flag that never runs, because 13-2.2.0 ships
  pre-extracted Postgres sources. Undefining HAVE_SPINLOCKS directly fixes it —
  slock_t is only typedef'd on that path. CI now builds v13 for real.

- protos/17 was stale relative to the branch we build. Purely additive
  (SummaryResult), so encoding was never at risk, but syncing it regenerated
  types/17 and enums/17. fetch:protos now follows the same repo and ref the
  WASM links against, so the schema can't drift from the library again.

Linking the deparser grows the WASM by ~285-434 KB (v17: +368 KB / +32%).
Isolated from toolchain drift by rebuilding v17 without deparse: 1,150,974
bytes vs 1,150,984 published, a 10-byte delta. It's linked unconditionally, so
parse-only users pay for it too; documented in every README.

538 tests pass: 7 proto, 72 on each of v13-v17, 133 on v18, 38 parser.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>